openarenafandomcom-20200216-history
OA3
OpenArena 3 (or OA3) is a planned reboot for OA. This reboot is what OA should always have been. It's set to happen in a future, though development on it has already started. It aims for visibility, performance and art consistency. The functionality of the gameplay (weapons, gamemodes, etc) is kept, OA3 only concerns to the assets (models, sound, textures, maps). The development goal is a smaller game in terms of filesize, a more detailed and colorful game with less skull clipart fallback, and a more optimized game than the original, as well as to be further distanced away from looking like the original while maintaining compatibilty with existing user-generated content. Note: some links in this page may bring to the "OA3" section of official OpenArena forums. At the moment, access to that forum section is restricted. However, feel free to post ideas and feedback in the other forum sections! Why OA3? Taken from Fromhell's words: "The reason why I skipped calling it OA2 is because 2.0's are cliche and also the number 3 works better for what this game is (since it well, uses id Tech 3)". By the way, it's not 100% sure that OA3 will be "official" name at the time of its release. What OA3 is NOT/will NOT be NOTTODO still applies here (plus OA3/NOTTODO), which means OA3 isn't: * OpenArena on a new engine. (OA without IdTech 3 is NOT OpenArena anymore, not to mention that closed source engines are an even bigger NO-NO) * A game made only for a specific audience. (There were many attempts to create public-specific forks of OA in the past; all of them failed) * A "throw everything you can find as long as is free" game. (This was the 0.x branch, and it ended up being for the worse) * A no-Q3 clone code-wise. (The functionality of the game will remain the same as it was from the first version of OA) * A Q3-clone artwork-wise. (There are already tons of other games following the "serious" thematics; there's no real need to be redundant; and last, but not least, we want to steer away from those thematics) Related discussions: * About imitating Q3 artwork-wise Art direction OA3's art direction aims for a strict non-knockoff/remake direction with anime influence reminiscent of (pretty) 2000 (not 2001-2009) games, examples of which include NVidia GeForce2 tech demos, Naomi arcade games and the Playstation 2 launch games, as well as the graphics tech available at the time (S3TC, T&L) which is really enough. Commonly cited influences are Shadowrun and Phantasy Star Online. Don't expect "4K/HD" fidelity, Y2K references, or nostalgia buzzwords like "retro oldschool loveletter epic". Reasons for this: * It's easily distinguishable from distances than 'real' or even western cartoon style. * It's far more shapely. * It mips down pretty well. * It can be much more expressive. * The hair can be 'solid', so no alpha channels necessary. * It's ripoff-less. Part of OpenArena's aim also has to do with OA steering away from the "Real Is Brown"/demonic/post-apocalyptic setting commonly found in a lot of shooters out there. This reboot should help into that. Related discussions: * Possible anime style. Assets Player models Player models will be redesigned and remodeled. * The triangle limit is between 1500 and 2250, with an average of 1600/2000 triangles max. 1400 triangles maximum total for highest LoD. * Each will have one surface per MD3 only * No alpha channels used * One texture per .skin * One 1024x1024x24 texture * Common frame ranges (max 200 fr) * Designed for distance. * No more animated than 21fps * Left hand would be mittenized (no individually modeled digits except for thumb and index finger), right hand would be a perma-fist. * Conception redesigned for clearer silhouette for defining character better. * More modest (honest!) * Lower/Upper/Head ONLY. Upper and head absolutely required - no more lower.md3-is-entire-model hacks. * Team Arena gesture animations * Optional torso run animation (similar to Bid For Power's implementation, synced to lower's run, so we don't need the lower.md3 body hack anymore) * One .blend file for characters (and their LODs) divided into Scenes, for easier re-exporting, animation maintenance. This will make production of player models much faster. * Animations will be 'shared' as much as possible between players, to shorten the production pipeline, save a ton of time reanimating the same running sequences, etc. Related discussions: * Player model proposed ideas * Player model ideas for already existing characters * Techniques to cheat lazy detail into skins * Automated model export scripting? * Player animation progress * Character artwork ** Sorceress's SDK * Angelyss's mount discussion * Artwork by Dancar * Possible concepts coming back * Silhouette concept art Weapons * Weapons looking more compact but distinguishable from distances, all redesigned. * Weapon HANDS visible. * 650 triangles maximum total for highest LoD. * One surface ever (second surface for muzzleflash only) * 512x256 texture. Related discussions: * Idea for weapon sprite handling * Ideas for the new Gauntlet model * Gun bound template Maps One of the most common complaints about OA is bad performance. Most of the performance issues comes from the assets, and more specifically from the game's maps. Hence, for OA3 maps, some rules will be followed. * Players should be visible with r_gamma 1 and without resorting to r_intensity. * The maps will have to achieve good looks, (no washed/single-textured maps) good performance, (constant FPS, check the guides at the Mapping resources & tutorials article for this) and good gameplay. * The game will be shipped only with unique, non-knockoff maps. Tributes and remakes of commercial games' maps enter the third-party territory. * Might not exceed 5mb uncompressed. * Must reach 30fps on Pentium II 233MHz computer with simple items. * Levelshots 128x128 at 8-bit color PCX format. * .aas files for bots are required. * Compile scripts (.sh's and .bats) are necessary.Windows can execute bats right off the bat, but can't do .sh, and linux can execute both. * They must have a defined music song. Related discussions: * Maps picked up for testing purposes * Additional requirements for maps * Map replacement/improvement/keeping discussion Textures * Textures 2X the Q3 standard (512 for 256) * Shader files should have prefixes for where their context is appropriate, such as: :* ui_ - for 2D shaders used by ui.qvm, mainly buttons, console, text, hud :* cg_ - for shaders used by cgame, this includes smoke trails, explosions, shells :* r_ - for shaders used by renderer, and so far this includes flares, sun :* players_ - for shaders used by player models (rare in this reboot) :* models_ - for shaders used by map models, item models, etcetera :* map_ - for shaders used specifically by maps, such as unique skies for example :* tex_ - for shaders used by maps in the textures/ folder :* Reuse as many common images as possible, (saves texture memory, loading times) for example muzzleflash shaders - they could be just the same grayscale texture, with different scale and colors defined in the shader. This should be only applied to effects that should not have shading from rgbGen lightingDiffuse. * Effects textures are no longer going to go in the textures/ folder, except for replacement Q3 textures. OA's effects shaders will use the gfx/fx folder. GUI * More multiplayer game types. * Monster killing cooperative campaign, invasions, gametypes. * Missionpack UI as the default UI. Related discussions: * More SP gamemodes * Multiplayer game browser idea * Debugging TA menu system Sound and music * Music: ** 44KHz Stereo ** OGG format Code-wise * Freetype and localization support. * Stats, optional account system (playing anonymously or playing with stats tracked, identifying by a "OAID#"), for a more integrated experience. * Reorganized, standardized pk3 build procedures. * Optional "console mode", to simplify play/interface for gamepad controllers, 10-feet gaming, and splitscreen play. * Optional "anchor" physics, for less bouncy gameplay/physics. (Done in 0.8.8, see Dmflags#Non-accelerated jumping) * Optional GLSL OpenGL 2.0 support. In concept, if scripts/etc.shader_glsl has a shader for a texture and glsl is activated, it'll override and use that. otherwise, it'll be normal and it will ignore the .shader_glsl files. See also Manual/Graphic options#GLSL effects. * Mod compatibility is still a main objective. Related discussions: * Reorganization of PK3 building process Other * Smaller file size in the end. * Possible use of Gitorious, as seen here. * GPLv2 license compatibility requirement still applies. Related discussions: * What's dropped and what's kept * Technical limits and conventions Notes External links * OA3 forum at official OA forums (Currently, registration required to access that section) * OA3 branch at MODDB * OA3 inspiration and stuff @ OpenGameArt - Discussion * OA3 Index @ the forums * OpenArena Discord server invite. OA Discord server includes an #oa3 section where OA staff shows some OA3 stuff. This invite link is required the first time only, then you can launch Discord directly from http://discordapp.com. * OpenArena code development on github ** Issue tracker for the Engine part ** Issue tracker for the Gamecode/UI code part See also * Current progress of OA3's non-maps assets * Current progress of OA3's maps * Current progress of Quake's Tribute Mappack * New shader commands which will be available in OA3 * Category:Development * OAX (gamecode changes testing) * OA3/NOTTODO * And the usual: DeveloperFAQ - NOTTODO - GoodPractices Category:Development